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1. Introduction 


Domainkeys Identified Mail [DKIM] allows an ADministrative Management 
Domain (ADMD) to take some responsibility for a [MAIL] message. Such 
responsibility can be taken by an Author’s organization, an 
operational relay (Mail Transfer Agent, or MTA), or one of their 
agents. Assertion of responsibility is made through a cryptographic 
Signature. Message transit from Author to recipient is through 
relays that typically make no substantive change to the message 
content and thus preserve the validity of the DKIM signature. 


In contrast to relays, there are intermediaries, such as Mailing List 
Managers (MLMs), that actively take delivery of messages, reformat 
them, and repost them, often invalidating DKIM signatures. The goal 
for this document is to explore the use of DKIM for scenarios that 
include intermediaries and recommend best current practices based on 
acquired experience. Questions that will be discussed include: 


o Under what circumstances is it advisable for an Author, or its 
organization, to apply DKIM to mail sent to mailing lists? 


o What are the trade-offs regarding having an MLM verify and use 
DKIM identifiers? 


o What are the trade-offs regarding having an MLM remove existing 
DKIM signatures prior to reposting the message? 


o What are the trade-offs regarding having an MLM add its own DKIM 
signature? 


These are open questions for which there may be no definitive 
answers. However, based on experience since the publication of the 
original version of [DKIM] and its gradual deployment, there are some 
views that are useful to consider and some recommended procedures. 


In general, there are two categories of MLMs in relation to DKIM: 
participating and non-participating. As each type has its own issues 
regarding DKIM-signed messages that are either handled or produced by 
them (or both), the types are discussed in separate sections. 


The best general recommendation for dealing with MLMs is that the MLM 
or an MTA in the MLM’s domain apply its own DKIM signature to each 
message it forwards and that assessors on the receiving end consider 
the MLM’s domain signature in making their assessments. (See 

Section 5, especially Section 5.2.) 
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With the understanding that this is not always possible or practical 
and the consideration that it might not always be sufficient, this 
document provides additional guidance. 


1.1. Background 


DKIM signatures permit an agent of the email architecture (see 
[EMAIL-ARCH]) to make a claim of responsibility for a message by 
affixing a validated domain-level identifier to the message as it 
passes through a relay. Although not the only possibility, this is 
most commonly done as a message passes through a boundary Mail 
Transport Agent (MTA) as it departs an ADministrative Management 
Domain (ADMD) across the open Internet. 


A DKIM signature will fail to verify if a portion of the message 
covered by one of its hashes is altered. An MLM commonly alters 
messages to provide information specific to the mailing list for 
which it is providing service. Common modifications are enumerated 
and described in Section 3.3. However, note that MLMs vary widely in 
behavior and often allow subscribers to select individual behaviors. 
Further, the MTA might make changes that are independent of those 
applied by the MLM. 


The DKIM Signatures specification [DKIM] deliberately rejects the 
notion of tying the signing domain (the "d=" tag in a DKIM signature) 
to any other identifier within a message; any ADMD that handles a 
message could sign it, regardless of its origin or Author domain. In 
particular, DKIM does not define any meaning to the occurrence of a 
match between the content of a "d=" tag and the value of, for 
example, a domain name in the RFC5322.From field, nor is there any 
obvious degraded value to a signature where they do not match. Since 
any DKIM signature is merely an assertion of "some" responsibility by 
an ADMD, a DKIM signature added by an MLM has no more or less meaning 
than a signature with any other "d=" value. 


1.2. MLMs in Infrastructure 


An MLM is an autonomous agent that takes delivery of a message and 
can repost it as a new message or construct a digest of it along with 
other messages to the members of the list (see [EMATL-ARCH], Section 
5.3). However, the fact that the RFC5322.From field of such a 
message (in the non-digest case) is typically the same as that of the 
original message, and that recipients perceive the message as "from" 
the original Author rather than the MLM, creates confusion about 
responsibility and autonomy for the reposted message. This has 
important implications for the use of DKIM. 
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Section 3.3 describes some of the things MLMs commonly do that 
produce broken signatures, thus reducing the perceived value of DKIM. 


Further, while there are published standards that are specific to MLM 
behavior (e.g., [MAIL], [LIST-ID], and [LIST-URLS]), their adoption 
has been spotty at best. Hence, efforts to specify the use of DKIM 
in the context of MLMs need to be incremental and value-based. 


Some MLM behaviors are well-established and their effects on DKIM 
signature validity can be argued as frustrating wider DKIM adoption. 
Still, those behaviors are not standards violations. Hence, this 
memo specifies practices for all parties involved, defining the 
minimum changes possible to MLMs themselves. 


A DKIM signature on a message is an expression of some responsibility 
for the message taken by the signing domain. An open issue that is 
addressed by this document is the ways a signature might be used by a 
recipient’s evaluation module, after the message has gone through a 
mailing list and might or might not have been rendered invalid. The 
document also considers how invalidation might have happened. 


Note that where in this document there is discussion of an MLM 
conducting validation of DKIM signatures or Author Domain Signing 
Practices ([ADSP]) policies, the actual implementation could be one 
where the validation is done by the MTA or an agent attached to it, 
and the results of that work are relayed by a trusted channel not 
specified here. See [AUTH-RESULTS] for a discussion of this. This 
document does not favor any particular arrangement of these agents 
over another; it merely talks about the MLM itself doing the work as 
a matter of simplicity. 


1.3. Feedback Loops and Other Bilateral Agreements 
A Feedback Loop (FBL) is a bilateral agreement between two parties to 
exchange reports of abuse. Typically, a sender registers with a 
receiving site to receive abuse reports from that site for mail 
coming from the sender. 
An FBL reporting address (i.e., an address to which FBL reports are 
sent) is part of this bilateral registration. Some FBLs require DKIM 
use by the registrant. 


See Section 6 for additional discussion. 


FBLs tend to use the [ARF] or the [IODEF] formats. 


Kucherawy Best Current Practice [Page 5] 


RFC 6377 DKIM and Mailing Lists September 2011 


1.4. Document Scope and Goals 


This document provides discussion on the above issues to improve the 
handling of possible interactions between DKIM and MLMs. In general, 
the preference is to impose changes to behavior at the Signer and 
Verifier rather than at the MLM. 


Wherever possible, the document’s discussion of MLMs is conceptually 
decoupled from MTAs despite the very tight integration that is 
sometimes observed in implementation. This is done to emphasize the 
functional independence of MLM services and responsibilities from 
those of an MTA. 


Parts of this document explore possible changes to common practice by 
Signers, Verifiers, and MLMs. The suggested enhancements are largely 
predictive in nature, taking into account the current email 
infrastructure, the facilities DKIM can provide as it gains wider 
deployment, and working group consensus. There is no substantial 
implementation history upon which these suggestions are based, and 
their efficacy, performance, and security characteristics have not 
yet been fully explored. 


2. Definitions 

2.1. Key Words 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[KEYWORDS]. 

2.2. Messaging Terms 
See [EMAIL-ARCH] for a general description of the current messaging 
architecture and for definitions of various terms used in this 
document. 

2.3. DKIM-Specific References 
Readers are encouraged to become familiar with [DKIM] and [ADSP], 


which are core specification documents, as well as [DKIM-OVERVIEW] 
and [DKIM-DEPLOYMENT], which are DKIM’s primary tutorial documents. 
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2.4. ‘'DKIM-Friendly’ 


The term "DKIM-friendly" is used to describe an email intermediary 
that, when handling a message, makes no changes to the message that 
cause valid [DKIM] signatures present on the message on input to fail 
to verify on output. 


Various features of MTAs and MLMs seen as helpful to users often have 
side effects that do render DKIM signatures unverifiable. These 
would not qualify for this label. 


2.5. Message Streams 


A "message stream" identifies a group of messages originating from 
within an ADMD that are distinct in intent, origin, and/or use and 
partitions them somehow (e.g., via changing the value in the "d=" tag 
value in the context of DKIM) so as to keep them associated to users 
yet distinct in terms of their evaluation and handling by Verifiers 
or Receivers. 


A good example might be user mail generated by a company’s employees, 
versus operational or transactional mail that comes from automated 
sources or marketing or sales campaigns. Each of these could have 
different sending policies imposed against them, or there might be a 
desire to insulate one from the other (e.g., a marketing campaign 
that gets reported by many spam filters could cause the marketing 
stream’s reputation to degrade without automatically punishing the 
transactional or user streams). 


3. Mailing Lists and DKIM 
It is important to make some distinctions among different styles of 
intermediaries, their typical implementations, and the effects they 
have in a DKIM-aware environment. 

3.1. Roles and Realities 
Across DKIM activities, there are several key roles in the transit of 


a message. Most of these are defined in [EMAIL-ARCH] but are 
reviewed here for quick reference. 


Author: The agent that provided the content of the message being 
sent through the system. The Author delivers that content to the 
Originator in order to begin a message’s journey to its intended 
final recipients. The Author can be a human using an MUA (Mail 
User Agent) or an automated process that may send mail (for 
example, the "cron" Unix system utility). 
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Originator: The agent that accepts a message from the Author, 
ensures it conforms to the relevant standards such as [MAIL], and 
then sends it toward its destination(s). This is often referred 
to as the Mail Submission Agent (MSA). 


Signer: Any agent that affixes one or more DKIM signature(s) to a 
message on its way toward its ultimate destination. There is 
typically a Signer running at the MTA that sits between the 
Author’s ADMD and the general Internet. The Originator and/or 
Author might also be a Signer. 


Verifier: Any agent that conducts DKIM signature validation. One is 
typically running at the MTA that sits between the public Internet 
and the Receiver’s ADMD. Note that any agent that handles a 
signed message can conduct verification; this document only 
considers that action and its outcomes either at an MLM or at the 
Receiver. Filtering decisions could be made by this agent based 
on verification results. 


Receiver: The agent that is the final transit relay for the message 
and performs final delivery to the recipient(s) of the message. 
Filtering decisions based on results made by the Verifier could be 
applied by the Receiver. The Verifier and the Receiver could be 
the same agent. This is sometimes the same as or coupled with the 
Mail Delivery Agent (MDA). 


In the case of simple user-to-user mail, these roles are fairly 
straightforward. However, when one is sending mail to a list and the 
mail then gets relayed to all of that list’s subscribers, the roles 
are often less clear to the general user as particular agents may 


hold multiple important but separable roles. The above definitions 
are intended to enable more precise discussion of the mechanisms 
involved. 


3.2. Types of Mailing Lists 
There are four common MLM implementation modes: 


aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one 
that makes no changes to the message itself as it redistributes; 
any modifications are constrained to changes to the [SMTP] 
envelope recipient list (RCPT commands) only. There are no 
changes to the message header or body at all, except for the 
addition of [MAIL] trace header fields. The output of such an MLM 
is considered to be a continuation of the Author’s original 
message transit. An example of such an MLM is an address that 
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expands directly in the MTA, such as a list of local system 
administrators used for relaying operational or other internal- 
only messages. See also Section 3.9.2 of [SMTP]. 


resending: A resending MLM (see Sections 5.2 and 5.3 of 
[EMATL-ARCH]) is one that may make changes to a message. The 
output of such an MLM is considered to be a new message; delivery 
of the original has been completed prior to distribution of the 
reposted message. Such messages are often reformatted, such as 
with list-specific header fields or other properties, to 
facilitate discussion among list subscribers. 


authoring: An authoring MLM is one that creates the content being 
sent as well as initiating its transport, rather than basing it on 
one or more messages received earlier. This is not a "mediator" 
in terms of [EMAIL-ARCH] since it originates the message, but 
after creation, its message processing and posting behavior 
otherwise do match the MLM paradigm. Typically, replies are not 
generated, or if they are, they go to a specific recipient and not 
back to the list’s full set of recipients. Examples include 
newsletters and bulk marketing mail. 


digesting: A special case of the resending MLM is one that sends a 
single message comprising an aggregation of recent MLM 
submissions, which might be a message of [MIME] type "multipart/ 
digest" (see [MIME-TYPES]). This is obviously a new message, but 
it may contain a sequence of original messages that may themselves 
have been DKIM-signed. 


In the remainder of this document, we distinguish two relevant steps 
corresponding to the following SMTP transactions: 


MLM Input: Originating user is Author; originating ADMD is 
Originator and Signer; MLM’s ADMD is Verifier; MLM’s input 
function is Receiver. 


MLM Output: MLM (sending its reconstructed copy of the originating 
user’s message) is Author; MLM’s ADMD is Originator and Signer; 
the ADMD of each subscriber of the list is a Verifier; each 
subscriber is a Receiver. 


Much of this document focuses on the resending class of MLM as it has 
the most direct conflict operationally with DKIM. 


The dissection of the overall MLM operation into these two distinct 
phases allows the DKIM-specific issues with respect to MLMs to be 
isolated and handled in a logical way. The main issue is that the 
repackaging and reposting of a message by an MLM is actually the 
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construction of a completely new message, and as such, the MIM is 
introducing new content into the email ecosystem, consuming the 
Author’s copy of the message, and creating its own. When considered 
in this way, the dual role of the MLM and its ADMD becomes clear. 


Some issues about these activities are discussed in Section 3.6.4 of 
[MAIL] and in Section 3.4.1 of [EMATL-ARCH]. 


3.3. Current MLM Effects on Signatures 


As described above, an aliasing MLM does not affect any existing 
signature, and an authoring MLM is always creating new content; thus, 
there is never an existing signature. However, the changes a 
resending MLM typically makes affect the RFC5322.Subject header 
field, the addition of some list-specific header fields, and/or the 
modification of the message body. The effects of each of these on 
DKIM verification are discussed below. 


Subject tags: A popular feature of MLMs is the "tagging" of an 
RFC5322.Subject field by prefixing the field’s contents with the 
name of the list, such as "[example]" for a list called "example". 
Altering the RFC5322.Subject field on new submissions by adding a 
list-specific prefix or suffix will invalidate the Signer’s 
signature if that header field was included in the hash when 
creating that signature. Section 5.5 of [DKIM] lists 
RFC5322.Subject as one that should be covered as it contains 
important user-visible text, so this is expected to be an issue 
for any list that makes such changes. 


List-specific header fields: Some lists will add header fields 
specific to list administrative functions such as those defined in 
[LIST-ID] and [LIST-URLS] or the "Resent-" fields defined in 
[MAIL]. It is unlikely that a typical MUA would include such 
fields in an original message, and DKIM is resilient to the 
addition of header fields in general (see notes about the "h=" tag 
in Section 3.5 of [DKIM]). Therefore, this is not seen as a 
concern. 


Other header fields: Some lists will add or replace header fields 
such as "Reply-To" or "Sender" in order to establish that the 
message is being sent in the context of the mailing list, so that 
the list is identified ("Sender") and any user replies go to the 
list ("Reply-To"). If these fields were included in the original 
message, it is possible that one or more of them may have been 
included in the signature hash, and those signatures will thus be 
broken. 
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Minor body changes: Some lists prepend or append a few lines to each 
message to remind subscribers of an administrative URL for 
subscription issues, of list policy, etc. Changes to the body 
will alter the body hash computed at the DKIM Verifier, so these 
will render any existing signatures that cover those portions of 
the message body unverifiable. [DKIM] includes the capability to 
limit the length of the body covered by its body hash so that 
appended text will not interfere with signature validation, but 
this has security implications. 


Major body changes: There are some MLMs that make more substantial 
changes to message bodies when preparing them for redistribution, 
such as adding, deleting, reordering, or reformatting [MIME] 
parts, "flattening" HTML messages into plain text, or inserting 
headers or footers within HTML messages. Most or all of these 
changes will invalidate a DKIM signature. 


MIME part removal: Some MLMs that are MIME-aware will remove large 
MIME parts from submissions and replace them with URLs to reduce 
the size of the distributed form of the message and to prevent 
inadvertent automated malware delivery. Except in some cases 
where a body length limit is applied in generation of the DKIM 
signature, the signature will be broken. 


There reportedly still exist some mailing lists in operation that are 
actually run manually by a human list manager, whose workings in 
preparing a message for distribution could include the above or even 
some other changes. 


In general, absent a general movement by MLM developers and operators 
toward more DKIM-friendly practices, an MLM subscriber cannot expect 
signatures applied before the message was processed by the MLM to be 
valid on delivery to a Receiver. Such an evolution is not expected 
in the short term due to general development and deployment inertia. 
Moreover, even if an MLM currently passes messages unmodified such 
that Author signatures validate, it is possible that a configuration 
change or software upgrade to that MLM will cause that no longer to 
be true. 


4. Non-Participating MLMs 


This section contains a discussion of issues regarding sending DKIM-— 
signed mail to or through an MLM that is not DKIM-aware. 
Specifically, the header fields introduced by [DKIM] and 
[AUTH-RESULTS] carry no special meaning to such an MLM. 
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4.1. Author-Related Signing 


In an idealized world, if an Author knows that the MLM to which a 
message is being sent is a non-participating resending MLM, the 
Author needs to be cautious when deciding whether or not to send a 
signed message to the list. The MLM could make a change that would 
invalidate the Author’s signature but not remove it prior to 
redistribution. Hence, list recipients would receive a message 
purportedly from the Author but bearing a DKIM signature that would 
not verify. Some mail filtering software incorrectly penalizes a 
message containing a DKIM signature that fails verification. This 
may have detrimental effects outside of the Author’s control. 
(Additional discussion of this is below.) This problem can be 
compounded if there are Receivers that apply signing policies (e.g., 
[ADSP]) and the Author publishes any kind of strict policy, i.e., a 
policy that requests that Receivers reject or otherwise deal severely 
with non-compliant messages. 


For domains that do publish strict ADSP policies, the originating 
site SHOULD use a separate message stream (see Section 2.5), such as 


a signing and Author subdomain, for the "personal" mail -- a 
subdomain that is different from domain(s) used for other mail 
streams. This allows each to develop an independent reputation, and 


more stringent policies (including ADSP) can be applied to the mail 
stream(s) that do not go through mailing lists or perhaps do not get 
signed at all. 


However, all of this presupposes a level of infrastructure 
understanding that is not expected to be common. Thus, it will be 
incumbent upon site administrators to consider how support of users 
wishing to participate in mailing lists might be accomplished as DKIM 
achieves wider adoption. 


In general, the stricter practices and policies are likely to be 
successful only for the mail streams subject to the most end-to-end 
control by the originating organization. That typically excludes 
mail going through MLMs. Therefore, site administrators wishing to 
employ ADSP with a "discardable" setting SHOULD separate the 
controlled mail stream warranting this handling from other mail 
streams that are less controlled, such as personal mail that transits 
MLMs. (See also Section 5.7 below.) 


4.2. Verification Outcomes at Receivers 
There is no reliable way to determine that a piece of mail arrived 
via a non-participating MLM. Sites whose users subscribe to non- 


participating MLMs SHOULD ensure that such user mail streams are not 
subject to strict DKIM-related handling policies. 
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4. 
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3. Handling Choices at Receivers 
In order to exempt some mail from the expectation of signature 
verification, as discussed in Section 4.1, receiving ADMDs would need 
to register non-participating lists and confirm that mail transited 
them. However, such an approach requires excessive effort and even 
then is likely to be unreliable. Hence, it is not a scalable 
solution. 
Any treatment of a verification failure as having special meaning is 
a violation of the basic DKIM Signatures specification [DKIM]. The 
only valid, standardized basis for going beyond that specification is 
with specific ADSP direction. 
Use of restrictive domain policies such as [ADSP] "discardable" 
presents an additional challenge. In that case, when a message is 
unsigned or the signature can no longer be verified, discarding of 
the message is requested. There is no exception in the policy for a 
message that may have been altered by an MLM, nor is there a reliable 
way to identify such mail. Therefore, participants SHOULD honor the 
policy and disallow the message. 
4. Wrapping a Non-Participating MLM 
One approach for adding DKIM support to an otherwise non- 
participating MLM is to "wrap" the MLM or, in essence, place it 
between other DKIM-aware components (such as MTAs) that provide some 
DKIM services. For example, the ADMD operating a non-participating 
MLM could have its DKIM Verifier act on messages from list 
subscribers, enforcing some of the features and recommendations of 
Section 5 on behalf of the MIM, and the MTA or MSA receiving the MLM 
Output could also add a DKIM signature for the MLM’s domain. 
Participating MLMs 
This section contains a discussion of issues regarding DKIM-signed 
mail that transits an MLM that is DKIM-aware. 
1. General 


Changes that merely add new header fields, such as those specified by 
[LIST-ID], [LIST-URLS], and [MAIL], are generally the most friendly 
to a DKIM-participating email infrastructure. Their addition by an 
MLM will not affect any existing DKIM signatures unless those fields 
were already present and covered by a signature’s hash, ora 
signature was created specifically to disallow their addition (see 
the note about "h=" in Section 3.5 of [DKIM]). 
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However, the practice of applying headers and footers to message 
bodies is common and not expected to fade regardless of what 
documents any standards body might produce. This sort of change will 
invalidate the signature on a message where the body hash covers the 
entire message. Thus, the following sections also discuss and 
suggest other processing alternatives. 


A possible mitigation to this incompatibility is use of the "l=" tag 
to bound the portion of the body covered by the DKIM body hash, but 
this is not workable for [MIME] messages; moreover, it has security 
considerations (see Section 3.5 of [DKIM]). Therefore, its use is 
discouraged. 


Expressions of list-specific policy (e.g., rules for participation, 
small advertisements, etc.) are often added to outgoing messages by 
MLM operators. There is currently no header field proposed for 
relaying such general operational MLM details apart from what 
[LIST-URLS] already supports. This sort of information is commonly 
included footer text appended to the body of the message or header 
text prepended above the original body. It is RECOMMENDED that 
periodic, automatic mailings to the list are sent to remind 
subscribers of list policy. It is also RECOMMENDED that standard 
header fields, rather than body changes, be used to express list 
operation parameters. These periodic mailings will be repetitive, of 
course, but by being generally the same each time, they can be easily 
filtered if desired. 


5.2. DKIM Author Domain Signing Practices 


ADSP presents a particular challenge. An Author domain posting a 
policy of "discardable" imposes a very tight restriction on the use 
of mailing lists, essentially constraining that domain’s users to 
lists operated by aliasing MLMs only; any MLM that alters a message 
from such a domain or removes its signature subjects the message to 
severe action by Verifiers or Receivers. A resending MLM SHOULD 
reject outright any mail from an Author whose domain posts such a 
policy, as those messages are likely to be discarded or rejected by 
any ADSP-aware recipients. See also the discussion in Section 5.3. 


Where such rejection of "discardable" mail is not enforced, and such 
mail arrives to a Verifier that applies ADSP checks that fail, the 
message SHOULD be either discarded (i.e., accept the message at the 
[SMTP] level but discard it without delivery) or rejected by 
returning a 5xx error code. In the latter case, some advice for how 
to conduct the rejection in a potentially meaningful way can be found 
in Section 5.11. 
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The reason for these recommendations is best illustrated by example. 
Suppose the following: 


o users Ul and U2 are subscribers of list L; 


o Ul is within an ADMD that advertises a "discardable" policy using 
ADSP; 


o L alters submissions prior to resending in a way that invalidates 
the DKIM signature added by U1’s ADMD; 


o U2’s ADMD enforces ADSP at the border by issuing an SMTP error 
code; and 


o L is configured to remove subscribers whose mail is bouncing. 


It follows then that a submission to L from Ul will be received at 
U2, but since the DKIM signature fails to verify, U2’s ADMD will 
reject it based on the ADSP protocol. That rejection is received at 
L, which proceeds to remove U2 from the list. 


See also Appendix B.5 of [ADSP] for further discussion. 
5.3. Subscriptions 


At subscription time, an ADSP-aware MLM SHOULD check for a published 
ADSP record for the new subscriber’s domain. If the policy specifies 
"discardable", the MLM SHOULD disallow the subscription or present a 
warning that the subscriber’s submissions to the mailing list might 
not be deliverable to some recipients because of the published policy 
of the subscriber’s ADMD. 


Of course, such a policy record could be created after subscription, 
so this is not a universal solution. An MLM implementation MAY do 
periodic checks of its subscribers and issue warnings where such a 
policy is detected or simply check upon each submission. 


5.4. Exceptions to ADSP Recommendations 


Where an ADMD has established some out-of-band trust agreement with 
another ADMD such that an Authentication-Results field applied by one 
is trusted by the other, the above recommendations for MLM operation 
with respect to ADSP do not apply because it is then possible to 
establish whether or not a valid Author signature can be inferred 
even if one is not present on receipt. 
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For example, suppose domains example.com and example.net have an 
explicit agreement to trust one another’s authentication assertions. 
Now, consider a message with an RFC5322.From domain of "example.org" 
that is also bearing a valid DKIM signature by the same domain, which 


arrives at a mailing list run by example.com. Upon evaluation, 
example.com validates the signature and adds an [AUTH-RESULTS] field 
indicating this. However, the MLM also makes changes to the message 


body that invalidate the signature. The MLM then re-signs the 
modified message using DKIM and sends it on to the list’s 
subscribers, one of whom is at example.net. 


On arrival at example.net, the DKIM signature for example.org is no 
longer valid, so ADSP would generally fail. However, example.net 
trusts the assertion of example.com’s Authentication-Results field 
that indicated that there was a valid signature from example.org, so 
the ADSP failure can be ignored. 


5.5. Author-Related Signing 


An important consideration is that Authors rarely have any direct 
influence over the management of an MLM. Specifically, the behavior 
of an intermediary (e.g., an MLM that is not careful about filtering 
out junk mail or being diligent about unsubscription requests) can 
trigger recipient complaints that reflect back on those agents that 
appear to be responsible for the message, in this case an Author via 
the address found in the RFC5322.From field. In the future, as DKIM 
signature outputs (i.e., the signing domain) are used as inputs to 
reputation modules, there may be a desire to insulate one’s 
reputation from influence by the unknown results of sending mail 
through an MLM. In that case, Authors SHOULD create a mail stream 
specifically used for generating DKIM signatures when sending traffic 
to MLMs. 


This suggestion can be made more general. Mail that is of a 
transactional or generally end-to-end nature, and not likely to be 
forwarded around by either MLMs or users, SHOULD be signed with a 
mail stream identifier different from that used for a stream that 
serves more varied uses. 


5.6. Verification Outcomes at MLMs 


MLMs typically attempt to authenticate messages posted through them. 
They usually do this through the trivial (and insecure) means of 
verifying the RFC5322.From field email address (or, less frequently, 
the RFC5321.MailFrom parameter) against a list subscription registry. 
DKIM enables a stronger form of authentication: the MLM can require 
that messages using a given RFC5322.From address also have a DKIM 
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signature with a corresponding "d=" domain. This feature would be 
somewhat similar to using ADSP, except that the requirement for it 
would be imposed by the MLM and not the Author’s organization. 


(Note, however, that this goes beyond DKIM’s documented semantics. 
It is presented as a possible workable enhancement.) 


As described, the MLM might conduct DKIM verification of a signed 
message to attempt to confirm the identity of the Author. Although 
it is a common and intuitive conclusion, few signed messages will 
include an Author signature (see [ADSP]). MLM implementers adding 
such support would have to accommodate this. For example, an MLM 
might be designed to accommodate a list of possible signing domains 
(the "d=" portion of a DKIM signature) for a given Author and 
determine at verification time if any of those are present. This 
enables a more reliable method of authentication at the expense of 
having to store a mapping of authorized signing domains for 
subscribers and trusting that it will be kept current. 


A message that cannot be thus authenticated MAY be held for 
moderation or rejected outright. 


This logic could apply to any list operation, not just list 
submission. In particular, this improved authentication MAY apply to 
subscription, unsubscription, and/or changes to subscriber options 
that are sent via email rather than through an authenticated, 
interactive channel such as the web. 


In the case of verification of signatures on submissions, MLMs SHOULD 
add an [AUTH-RESULTS] header field to indicate the signature(s) 
observed on the submission as it arrived at the MLM and what the 
outcome of the evaluation was. Downstream agents might or might not 
trust the content of that header field depending on their own a 
priori knowledge of the operation of the ADMD generating (and, 
preferably, signing) that header field. See [AUTH-RESULTS] for 
further discussion. 


5.7. Signature Removal Issues 


A message that arrives signed with DKIM means some domain prior to 
MLM Input has made a claim of some responsibility for the message. 
An obvious benefit to leaving the input-side signatures intact, then, 
is to preserve that original assertion of responsibility for the 
message so that the Receivers of the final message have an 
opportunity to evaluate the message with that information available 
to them. 
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However, if the MLM is configured to make changes to the message 
prior to reposting that would invalidate the original signature(s), 
further action is RECOMMENDED to prevent invalidated signatures from 
arriving at final recipients, possibly triggering unwarranted filter 
actions. (Note, however, that such filtering actions are plainly 
wrong; [DKIM] stipulates that an invalid signature is to be treated 
as no signature at all.) 


A possible solution would be to: 


1. Attempt verification of all DKIM signatures present on the input 
message; 


2. Apply local policy to authenticate the identity of the Author; 
3. Remove all existing [AUTH-RESULTS] fields (optional); 


4. Add an [AUTH-RESULTS] header field to the message to indicate the 
results of the above; 


5. Remove all previously evaluated DKIM signatures; 


6. Affix a new signature that includes in its hashes the entire 
message on the output side, including the Authentication—-Results 
header field just added (see Section 5.8). 


Removing the original signature(s) seems particularly appropriate 
when the MLM knows it is likely to invalidate any or all of them due 
to the nature of the reformatting it will do. This avoids false 
negatives for list subscribers in their roles as Receivers of the 
message; although [DKIM] stipulates that an invalid signature is the 
same as no Signature, it is anticipated that there will be some 
implementations that ignore this advice. 


The MLM could re-evaluate existing signatures after making its 
message changes to determine whether or not any of them have been 
invalidated. The cost of this is reduced by the fact that, 
presumably, the necessary public keys have already been downloaded 
and one or both of the message hashes could be reused. 


Per the discussion in [AUTH-RESULTS], a Receiver’s choice to put any 
faith in the veracity of the header field requires an a priori 
assessment of the agent that created it. Absent that assessment, a 
Receiver cannot interpret the field as valid. Thus, the final 
recipients of the message have no way to verify on their own the 
authenticity of the Author’s identity on that message. However, if 
that field is the only one on the message when the Verifier gets it, 
and the Verifier explicitly trusts the Signer that included the 
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Authentication-Results field in its header hash (in this case, the 
MLM), the Verifier is in a position to believe that a valid Author 
signature was present on the message. 


This can be generalized as follows: a Receiver SHOULD consider only 
[AUTH-RESULTS] fields bearing an authserv-id that appears ina list 
of sites the Receiver trusts and that is also included in the header 
hash of a [DKIM] signature added by a domain in the same trusted 
list. 


Since an aliasing MLM makes no substantive changes to a message, it 
need not consider the issue of signature removal as the original 
signatures should at least arrive to the next MTA unmodified. It is 
possible that future domain-based reputations would prefer a richer 
data set on receipt of a message, and, in that case, signature 
removal would be undesirable. 


An authoring MLM is closed to outside submitters; thus, much of this 
discussion does not apply in that case. 


5.8. MLM Signatures 


DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own 
signatures when distributing messages. The MLM is responsible for 
the alterations it makes to the original messages it is resending and 
should express this via a signature. This is also helpful for 
getting feedback from any FBLs that might be set up so that undesired 
list mail can generate appropriate action. 


MLM signatures will likely be used by recipient systems to recognize 
list mail, and they give the MLM’s ADMD an opportunity to develop a 
good reputation for the list itself. 


A signing MLM, as any other MLM, is free to omit redistribution of a 
message if that message was not signed in accordance with its own 
local configuration or policy. It could also redistribute but not 
sign such mail. However, selective signing is NOT RECOMMENDED; 
essentially that would create two message streams from the MLM, one 
signed and one not, which can confuse DKIM-aware Verifiers and 
Receivers. 


A signing MLM could add a List-Post: header field (see [LIST-URLS]) 
using the DNS domain matching the one used in the "d=" tag of the 
DKIM signature that is added by the MLM. This can be used by 
Verifiers or Receivers to identify the DKIM signature that was added 
by the MLM. This is not required, however; it is believed the 
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reputation of the Signer will be a more critical data point than this 
suggested binding. Furthermore, this is not a binding recognized by 
any current specification document. 


A DKIM-aware resending MLM SHOULD sign the entire message after the 
message is prepared for distribution (i.e., the MLM Output from 
Section 3.2). Any other configuration might generate signatures that 
will not validate. 


DKIM-aware authoring MLMs sign the mail they send according to the 
regular signing guidelines given in [DKIM]. 


One concern is that having an MLM apply its signature to unsigned 
mail might cause some Verifiers or Receivers to interpret the 
signature as conferring more authority or authenticity to the message 
content than is defined by [DKIM]. This is an issue beyond MLMs and 
primarily entails receive-side processing outside of the scope of 
[DKIM]. It is, nevertheless, worth noting here. 


5.9. Verification Outcomes at Final Receiving Sites 


In general, Verifiers and Receivers SHOULD treat a signed message 
from an MLM like any other signed message; indeed, it would be 
difficult to discern any difference since specifications such as 
[LIST-URLS] and [LIST-ID] are not universally deployed and can be 
trivially spoofed. 


However, because the Author domain will commonly be different from 
the MLM’s signing domain, there may be a conflict with [ADSP] as 
discussed in Sections 4.3 and 5.7, especially where an ADMD has 
misused ADSP. 


5.10. Use with FBLs 


An FBL operator might wish to act on a complaint from a user about a 
message sent to a list. Some FBLs could choose to generate feedback 
reports based on DKIM verifications in the subject message. Such 
operators SHOULD send a report to each domain with a valid signature 
that has an FBL agreement established, as DKIM signatures are claims 
of some responsibility for that message. Because Authors generally 
have limited control over the operation of a list, this point makes 
MLM signing all the more important. 


MLM operators SHOULD register with FBLs from major service providers. 
In the context of DKIM, there SHOULD be an exchange of information 
with the FBL provider including what signing domain the MLM will use, 
if any. 
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Where the FBL wishes to be more specific, it MAY act solely on a DKIM 
signature where the signing domain matches the DNS domain found in a 
List-Post: header field (or similar). 


Use of FBLs in this way SHOULD be made explicit to list subscribers. 
For example, if it is the policy of the MLM’s ADMD to handle an FBL 
item by unsubscribing the user that was the apparent sender of the 
offending message, advising subscribers of this in advance would help 
to avoid surprises later. 


A DKIM-signed message sent to an MLM, and then distributed to all of 
a list’s recipients, could result in a complaint from one of the 
final recipients for some reason. This could be an actual complaint 
from some subscriber that finds the message abusive or otherwise 
undesirable, or it could be an automated complaint such as Receiver 
detection of an invalidated DKIM signature or some other condition. 
It could also be a complaint that results from antagonistic behavior, 
such as is common when a subscriber to a list is having trouble 
unsubscribing and then begins issuing complaints about all 
submissions to the list. This would result in a complaint being 
generated in the context of an FBL report back to the message Author. 
However, the original Author has no involvement in operation of the 
MLM itself, meaning the FBL report is not actionable and is thus 
undesirable. 


5.11. Handling Choices at Receivers 


A recipient that explicitly trusts signatures from a particular MLM 
MAY wish to extend that trust to an [AUTH-RESULTS] header field 
signed by that MLM. The recipient MAY then do additional processing 
of the message, using the results recorded in the Authentication- 
Results header field instead of the original Author’s DKIM signature. 
This includes possibly processing the message as per ADSP 
requirements. 


Receivers SHOULD ignore or remove all unsigned externally applied 
Authentication-Results header fields and those not signed by an ADMD 
that can be trusted by the Receiver. See Sections 5 and 7 of 
[AUTH-RESULTS] for further discussion. 


Upon DKIM and ADSP evaluation during an SMTP session (a common 
implementation), an agent MAY decide to reject a message during an 
SMTP session. If this is done, [SMTP] stipulates that 550 is the 
correct response code. However, if the SMTP server supports 
[ENHANCED] status codes, a status code not normally used for "user 
unknown" (5.1.1) is preferred; therefore, a 5.7.0 code SHOULD be 
used. If the rejecting SMTP server supports this, it thus makes a 
distinction between messages rejected deliberately due to policy 
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decisions rather than those rejected because of other delivery 
issues. In particular, a policy rejection SHOULD be relayed using 
the above enhanced status code and some appropriate wording in the 
text part of the reply. Those MLMs that automatically attempt to 
remove users with prolonged delivery problems (such as account 
deletion) SHOULD thus detect the difference between policy rejection 
and other delivery failures and act accordingly. It would also be 
beneficial for SMTP servers doing so to use appropriate wording in 
the text portion of the reply, perhaps explicitly using the string 
"ADSP" to facilitate searching for relevant data in logs. 


The preceding paragraph does not apply to an [ADSP] policy of 
"discardable". In such cases where the submission fails that test, 
the Receiver or Verifier SHOULD discard the message but return an 
SMTP success code, i.e., accept the message but drop it without 
delivery. An SMTP rejection of such mail instead of the requested 
discard action causes more harm than good. 


6. DKIM Reporting 


As mechanisms become available for reporting forensic details about 
DKIM verification failures, MLMs will benefit from their use. 


MLMs SHOULD apply DKIM failure-reporting mechanisms as a method for 
providing feedback to Signers about issues with DKIM infrastructure. 
This is especially important for MLMs that implement DKIM 
verification as a mechanism for authentication of list configuration 
commands and submissions from subscribers. 


7. Security Considerations 


This document provides suggested or best current practices for use 
with DKIM and, as such, does not introduce any new technologies for 
consideration. However, the following security issues should be 
considered when implementing the practices described in this 
document. 


7.1. Security Considerations from DKIM and ADSP 
Readers should be familiar with the material in the "Security 


Considerations" sections in [DKIM], [ADSP], and [AUTH-RESULTS] as 
appropriate. 
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7.2. Authentication Results When Relaying 


Section 5 advocates addition of an [AUTH-RESULTS] header field to 
indicate authentication status of a message received as MLM Input. 
Per Section 7.2 of [AUTH-RESULTS], Receivers generally should not 
trust such data without a good reason to do so, such as an a priori 
agreement with the MLM’s ADMD. 


Such agreements are strongly advised to include a requirement that 
those header fields be covered by a [DKIM] signature added by the 
MLM’ s ADMD. 
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Appendix B. Example Scenarios 
This section describes a few MLM-related DKIM scenarios that were 
part of the impetus for this work and the recommended resolutions for 
each. 

Balk MLMs and ADSP 
Problem: 


o Author ADMD advertises an ADSP policy of "dkim=discardable" 


o Author sends DKIM-signed mail to a non-participating MLM, which 
invalidates the signature 


o Receiver MTA checks DKIM and ADSP at SMTP time and is configured 
to reject ADSP failures, so rejects this message 


O process repeats a few times, after which the MLM unsubscribes the 
Receiver 


Solution: MLMs should refuse mail from domains advertising ADSP 
policies of "discardable" unless the MLMs are certain they make no 
changes that invalidate DKIM signatures. 

B.2. MLMs and FBLs 


Problem: 


o subscriber sends signed mail to a non-participating MLM that does 
not invalidate the signature 


o a recipient reports the message as spam 


o FBL at recipient ADMD sends report to contributor rather than list 
manager 
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Solution: MLMs should sign 
existing signatures. FBLs 
subscribers where such can 
report to all parties with 
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Cloudmark 
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mail they send and might also strip 

should report to list operators instead of 
be distinguished; otherwise, FBLs should 
valid signatures. 
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